“Desktop-as-a-Service” (DaaS) is a computing paradigm in which a service provider (e.g., a corporate IT department, a third-party provider, etc.) centrally manages and delivers desktop operating system environments (i.e., “desktops”) and associated application software to users as a cloud-based service. This allows the users to access their personalized desktops and applications from any number of client devices, and from any location (e.g., home, work, temporary office, etc.). This also allows the service provider to maintain centralized control over the users' desktop data and resources, resulting in increased reliability, security, and operational efficiency.
One limitation of DaaS in general is that, while it enables portability of user desktops and associated applications, it does not enable portability of another key aspect of a user's typical work environment—the user's telephone. This limitation can be problematic in several scenarios. For example, consider a scenario where users A and B are employees of an organization involved in time-critical and/or confidential business (e.g., financial, military, government, medical, legal, etc.). Assume that user A decides to work from home one day and accesses his/her office desktop remotely via DaaS. Further assume that user B attempts to call user A at his/her office telephone number for a critical, confidential query (e.g., a query that can only be communicated verbally) while user A is working from home. In this case, since user A is not available at his/her office telephone number, user B may be forced to call user A at an external telephone number, such as user A's home or cell phone number. This outcome is inefficient because user B may need to expend time and energy attempting to determine user A's external telephone number. This outcome also raises security concerns because the call to user A's external telephone number will likely be routed over a public telephone network (instead of the organization's jute mal telephone network).
To work around the limitation above, some DaaS service providers install a generic softphone client as a native application within each user's desktop. With this approach, a user can launch the softphone client from his/her desktop, login to a telephony service, and thereafter use the softphone client to send and receive phone calls at an assigned telephone number (which can be made known to others in the same group, organization, etc.) through the telephony service. However, this approach suffers from a number of drawbacks. First, since the softphone client is delivered as a native desktop application, the user must request and access his/her desktop before using the softphone client. In other words, there is no way for the user to access the softphone client alone as a separate and independent resource. This leads to inefficiencies on the service provider side, since the DaaS service provider will need to allocate server resources to deliver the user's full desktop to his/her client device, even if the user only wants access to the softphone client for telephony purposes.
Second, since the softphone client is generic to all users (in other words, the DaaS service provider does not dynamically configure the softphone client on a per-user basis), the DaaS service provider generally will not have any visibility into, or control over, the mapping of users to telephony accounts/telephone numbers. As a result, the DaaS service provider cannot explicitly provision telephone numbers to users or monitor telephone usage metrics.
Third, the foregoing approach requires that a user login at least twice in order to use the softphone client: once to login to the DaaS service (via a DaaS client) and again to login to the telephony service (via the softphone client). As a result, the user must keep track of two different access points and two different sets of login credentials, which can be burdensome and potentially error-prone.